Subject: Comments on CANUREACH DSAP field for SNA

From: alan bartky <[email-masked]>
Date: Wed, 16 Jun 93 12:55:43 PDT

After Reading Jim Cobban's (BNR), Himanshu Shah's (Proteon) comments and
then reading RFC1434 again I have concluded the following.

1) Jim is correct in that the TEST frame sent out on the destination ring
should send out the TEST frame with a DSAP of 0.

2) Jim is also correct in that if the CANUREACH message sets the DSAP=SSAP,
it will cause the circuit IDs to only work if the DSAP=SSAP (as shown
in the diagram of RFC1434 page 10 in section 4.1.1).

This would cause DLSw to only work for LLC connections that have DSAP=SSAP.
All SDLC to LLC converter products must use multiple SAPs in order to
establish multiple LLC2 connections on behalf of the downstream SDLC PUs.

If the DSAP=SSAP method is currently being used by the 6611, then 
the 6611 would not work properly with SDLC to LLC converters that are
connected on downstream LANs from the 6611!

3) Himanshu's suggestion that the DSAP in the CANUREACH message be hard
coded to 4 would work in most cases but not all.  If an SNA Host were to 
contact a downstream SNA device (SNA outdial on token ring) it's DSAP
would be 4 and the downstream LLC Device may not necessarily be 4.  Again
if it were a converter or other downstream device that used a SAP value other
than 4, the value would not work.  It also would not work for upstream
connections where the SAP was not 4 (either another converter or an SNA
host were configured for a SAP of 8 or 0x0C, look it up in your IBM manuals,
it's allowed).

4) The diagram under 4.1.1. does not show the XID exchange sequence.  I
don't know of any SNA connect sequence that does not use XIDs.  It should
be in the diagram (it does mention later that XID frames may be exchanged
once the circuit is established).

5) Some SNA devices use an XID rather than a TEST frame to establish a
source route path (including some IBM products).  These devices must
be supported also.

6)  It seems to me that the real function of a CANUREACH should be only
to determine if a given MAC address can be reached and that it should not
be used to set the circuit ID.  The circuit ID would be best to be set
when the first XID (or TEST) frame was sent with a DSAP that is not equal
to 0.  This would eliminate the problem of trying to arbitrarily set the
DSAP=SSAP which is not always a valid assumtion.  In SNA the first XID
after the TEST message contains a valid DSAP and SSAP rather than using
a SAP of 0.  I am not as knowledgeable about NETBIOS, but if it uses a 
TEST or an XID with a DSAP of F0, then that would be the appropriate time
to set the circuit ID.

As far as item 6 goes, I am still of the opinion that we should try to
come to a quick conclusion as far as agreeing on the RFC.  I will not
however agree to any standard that causes SDLC to LLC conversion to not
interoperate with DLSw.  It may be necessary to use Himanshu's sugestion
of hard coding the DSAP to 4 in order to proceed (at least it would work
for most cases).

After understanding this issue more, I would definetly want to discuss it
next week in Raleigh during the technical discussions.

Regards,
Alan K. Bartky ([email-masked]) 714-588-2070
Sync Research Inc.